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1 DELIVERY OF CALL QUEUE MESSAGES FOR CALLS 

2 LAUNCHED FROM THE INTERNET 

3 BACKGROUND OF THE INVENTION 

4 The present invention relates to notifying a telecommunication network customer of call 

5 status, and more particularly, is directed to transporting, via the Internet, a message regarding a 

6 queue length for a call waiting for service at a call center. 

7 Telemarketing, the sale of products and services to customers over the telephone, is one 

8 of the fastest growing businesses around the world. In a typical call center, telemarketing agents 

9 are equipped with a telephone terminal for answering telephone calls placed by customers. 

10 Typically, call centers have toll-free numbers such as "800" nvmibers. 

1 1 Fig. 1 shows a configuration for telemarketing including telephone 1 0, assumed to be at a 

12 customer premises, telecommunication network 20, and corporate premises 80. 

13 Telecommunication network 20 includes switch 30, service control point (SCP) 40, and 

14 intelligent peripheral (IP) 50. Network 20 may be the public switched telephone network 

15 (PSTN). Corporate premises 80 includes private branch exchange (PBX) 60 coupled to call 

16 center 70. PBX 60 and call center 70 may be co-located or in different locations. 

17 SCP 40 includes a computer programmed to queue calls waiting for service at call center 

18 70 inside telecommunication network 20, to estimate the time-in-queue for an enqueued call, and 

19 to notify enqueued callers of their estimated time-in-queue. 

20 PBX 60 includes queue manager 64 and router 62. Queue manager 64 queues and 

21 dequeues incoming calls from telecommunication network 20 based on an appropriate queue 

22 discipline, such as first in first out. Router 62 routes calls to call center 70 for delivery to an 
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1 appropriate agent using a skill matrix or other criteria. Call center 70 is an automatic call 

2 distribution (ACD) system for coupling calls from PBX 60 to agents at stations 72, 74, 76. 

3 Figs. 2A-2C are flow charts illustrating operation of the configuration of Fig. 1 . 

4 Referring to Fig. 2 A, at step 205, a user places a call to call center 70 using telephone 10 

5 by dialing a toll-free nimiber of call center 70. 

6 At step 210, switch 30 in telecommunication network 20 receives the dialed number from 

7 telephone 1 0. At step 215, switch 30 determines that the nvmiber is a toll-free number, that is, an 

8 "800", "888" or similar number. At step 220, switch 30 requests instructions for the received 

9 toll-free number from SCP 40. 

10 At step 225, SCP 40 receives the toll-free number from switch 30. At step 230, SCP 40 

1 1 retrieves a stored record for the toll-free number. The stored record for the toll-free number 

12 includes an actual phone number and information including whether the called phone nimiber 

13 has "call center with queue length" service. 

14 Let it be assumed that the called phone number has "call center with queue length" 

15 service, and that the called telephone niunber is associated with PBX 60. At step 235, SCP 40 

1 6 queries queue manager 64 of PBX 60 as to whether a new call can be immediately connected to 

1 7 call center 70. 

1 8 At step 240, queue manager 64 receives the query from SCP 40. At step 245, queue 

19 manager 64 determines whether a new call can be accommodated by call center 70, such as by 

20 checking whether the number of calls in progress is less than the maximum which can be 

21 accommodated by call center 70. If the call from telephone 10 can be connected immediately, 

22 processing proceeds to step 300 in Fig. 2C. 
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1 Let it be assumed that a call cannot be immediately connected. At step 250, queue 

2 manager 64 sends an unavailability reply to SCP . 

3 At step 255, SCP 40 receives the unavailability reply from queue manager 64. 

4 Referring now to Fig. IB, at step 260, upon receiving the message from queue manager 

5 64 that a new call cannot be immediately accommodated, SCP 40 instructs IP 50 to execute a 

6 stored program to deliver an announcement to telephone 10. Specifically, SCP 40 sends a 

7 predetermined type of message accompanied by information to be included in the announcement, 

8 such as estimated time-in-queue. 

9 At step 265, IP 50 receives the instruction to deliver the announcement from SCP 40. At 

10 step 270, IP 50 delivers the announcement to svdtch 30. The announcement is a message 

1 1 reflecting the information sent at step 260 such as, "There are two calls ahead of you, and your 

12 call should be connected in 4 minutes," or a pre-recorded message selected in accordance with 

1 3 the information sent at step 260. 

14 Meanwhile, at step 275, SCP 40 instructs switch 30 to connect the call from telephone 10 

15 to IP 50. It will be appreciated that step 275 is performed substantially simultaneously with step 

16 260. 

17 At step 280, switch 30 receives the call connection instruction from SCP 40. At step 285, 

18 in response to the call connection instruction from SCP 40, switch 30 switches the call from 

19 telephone 10 to port 3 1 for coupling to IP 50. At step 290, a call path is established where 

20 intelligent peripheral 50 plays an announcement for telephone 10. 
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1 At step 276, SCP 40 checks whether a predetermined amount of time has elapsed since 

2 telephone 10 has been connected to IP 50. If not, then the check at step 276 is repeated. After 

3 the predetermined amoimt of time has elapsed, processing proceeds to step 279. 

4 Let it now be assumed that, at step 296 of Fig. 2B, call center 70 determines that an agent 

5 is free to service a new call, and so notifies queue manager 64. At step 297, queue manager 64 

6 forwards the agent availability notice to SCP 40. 

7 At step 277, SCP 40 receives the notice of an available agent. At step 278, SCP 40 

8 determines whether there are calls which have been enqueued longer than the call from telephone 

9 1 0. If not, then the call from telephone 1 0 can be connected to call center 70, and processing 

10 proceeds to step 330 of Fig. 2C. If there are calls ahead of the call from telephone 10, then 

1 1 processing proceeds to step 279 of Fig. 2B. 

12 At step 279, SCP 40 prepares an update announcement, reflecting its new estimated time- 

13 in-queue for the call. The estimate is based on the number of calls accepted by PBX 60 since an 

14 announcement was last played to the enqueued caller and/or decrementing the estimated time-in- 

15 queue to reflect passage of time. SCP 40 sends its updated announcement information to IP 50. 

16 At step 271, IP 50 receives the updated amiouncement, and proceeds to step 270 to generate an 

17 appropriate announcement and deliver it to telephone 10. Meanwhile, SCP 40 proceeds to step 

1 8 276 and waits for time to pass or an agent availability message to arrive from queue manager 64. 

19 Referring now to Fig. 2C, at step 300, queue manager 64 sends an availability reply to 

20 SCP 40. At step 305, which may be performed substantially simultaneously with step 300, 

21 queue manager 64 instructs router 62 to switch the incoming call to call center 70 for delivery to 

22 an available agent. 
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1 At step 3 1 0, router 62 receives the instruction from queue manager 64. At step 3 1 2, a 

2 voiceband connection is established between an available agent at call center 70 and PBX 60. 

3 At step 3 1 5, router 62 switches the available agent to the incoming call, and, at step 320, 

4 a call path is established between telephone 10 and an agent at station 72. 

5 Meanwhile, at step 325, SCP 40 receives the availability reply from queue manager 64. 

6 At step 330, SCP 40 instructs IP 50 to stop its announcement. 

7 At step 340, IP 50 receives the instruction from SCP 40 and, at step 345, stops its 

8 announcement. 

9 At step 350, SCP 40 instructs switch 30 to connect telephone 1 0 to port 32 for connection 

1 0 to the telephone number associated with PBX 60, as obtained from the stored record retrieved by 

1 1 SCP 40 at step 225 in Fig. 2A. 

^ 2 At step 355, switch 30 receives the call connection instruction from SCP 40. At step 357, 

1 3 a voiceband connection is established between telephone 1 0 and port 32, and another voiceband 

14 connection is established between port 32 and PBX 60. 

1 5 At step 360, switch 30 switches the call from telephone 1 0 to port 32 for connection to 

1 6 PBX 60. At step 3 65, a call path is established between telephone 1 0 and an agent at station 72 

17 of call center 70. 

1 8 At step 370, telephone 1 0 is coupled to the circuit established to the available agent at 

19 station 72 of call center 70. 

20 At step 375, station 72 is coupled to the circuit established to telephone 1 0. 

2 1 One problem with the above-described arrangement is that IP 50 is relied upon. There 

22 may not be enough intelligent peripherals in telecommunications network 20 to adequately 
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1 support the call queue message service. Another problem is the large amount of resources 

2 consumed in comiecting IP 50 to switch 30, when the originating switch does not have a directly 

3 connected IP. A further problem is that the above described arrangement ties up the user's 

4 telephone and a port on the originating switch. 

5 Accordingly, there is a need for an improved way to deliver call queue information from 

6 PBX 60 to the user of telephone 1 0. 
7 
8 
9 



SUMMARY OF THE INVENTION 
In accordance with an aspect of this invention, there is provided a method of and 

10 apparatus for setting up a call between a subscriber premises and a call center. A call set up 

1 1 request is received from a gateway responsive to the subscriber premises. A query is sent to the 

12 call center. An availability reply is received from the call center, and a call set up instruction is 

1 3 prepared for setting up the call between the subscriber premises and the call center. 

14 In some cases, an unavailability reply is received from the call center. The time-in-queue 

15 until the call center will be available to receive the call is estimated, and a call queue status 

16 message is prepared for delivery to the gateway and thence to the subscriber premises. The 

1 7 subscriber premises includes a personal computer and a telephone. 

18 It is not intended that the invention be summarized here in its entirety. Rather, fiirther 

19 features, aspects and advantages of the invention are set forth in or are apparent from the 

20 following description and drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



Fig. 1 is a block diagram showing a prior art telemarketing configuration; 
Figs. 2A-2C are a flow chart illustrating operation of the configuration of Fig. 1 ; 

4 Fig. 3 is a block diagram showing a telecommunication network in which the present 

5 invention is applied; 

6 Fig. 4A is a block diagram showing dialer agent 105 residing in personal computer 101; 

7 Fig. 4B is a block diagram showing dialer agent 106 residing in Internet service provider 

8 152; 

9 Fig. 4C is a block diagram showing dialer agent 107 residing in a third party provider or a 

10 gateway; 

1 1 Figs. 5A-5C are a flow chart illustrating operation of the configuration of Fig. 3; 

1 2 Fig. 6 is a chart showing a click to dial request; and 
13 



14 



Fig. 7 is a chart showing a call set up request sent from gateway 160 to PBX 60. 



DETAILED DESCRIPTION 

1 5 Fig. 3 shows a configuration in which the present invention is applied. The configuration 

16 includes subscriber premises 1 10, telecommunication network 120, Internet service provider 

17 (ISP) 150, Internet 155, gateway 160 that couples telecommunication network 120 and ISP 150, 

18 and coiporate premises 80. Corporate premises 80 is assumed to be substantially the same as in 

19 Fig. 1, that is, the present technique is operative with no changes at corporate premises 80. 

20 Subscriber premises 1 10 includes telephone 10 and personal computer (PC) 100. 

21 Telephone 10 is coupled to switch 130 of telecommunication network 120. PC 100 is coupled to 

22 ISP 1 50 via a conventional network connection such as a modem. 
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1 In some embodiments, PC 100 is operative using a telephony applications program 

2 interface (API) to generate dual tone multi-frequency (DTMF) tones in response to stored or 

3 dynamically entered telephone numbers, that is, to act as a "phone dialer", obviating the need for 

4 the subscriber to "dial" a telephone number using the keypad of telephone 10. 

y'^^T^ ^I^^^P'ipr ^^' '^ ** ' ^ rml i r i Himint i n whirh thr nifr^rnhpr hag two tp l ephone lines. In_Q theP^ 

6 embodiments, the subscriber has only one telephpne line and uses an appropriate scheme to 

7 — py< w i ilM Om i i-h MmX \ \ ' a \' a vh i vii'H«j lui ^in^ l H -jjtri H -«j iir 4 t : \< ^ Vi -i iri' - A^'nr Tntnmpt PrntniW-^m) , ^ 

8 Telecommimication network 120 of Fig. 3 includes switch 130 and service control point 

9 (SCP) / service node (SN) 140. SCP/SN 140 includes a general purpose computer programmed 
ill 10 to provide SCP fimctions and SN functions. SCP functions are directed to controlling other 

i i;:- 1 1 network elements such as switch 130, estimating the time-in-queue for an enqueued call, 

i,t;i 12 reporting the status of an enqueued call, and so on. SN functions are those necessary to interface 

13 with gateway 160 and the SCP functions. In Fig 3, the SCP and SN functions are shown as co- 

14 located. In other embodiments, the SCP and SN functions are located in separate elements of 

% 15 telecommunication network 120. SCP/SN 140 is coupled to switch 130, gateway 160, and queue 

16 manager 64 of PBX 60 located at corporate premises 80. 

17 ISP 150 is an Internet service provider such as AT&T Worldnet. In another embodiment, 

18 the functions of ISP 150 are provided by a server of a corporation. ISP 150 is coupled to Intemet 

19 155. 

20 Gateway 160 is coupled to Intemet 155 and SCP/SN 140 of PSTN 150. Gateway 160 

21 functions as an Intemet web site for providing a so-called "click to dial" service in which a user 

22 initiates a telephone call by clicking on a location of a web page supplied by gateway 160. In 
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1 particular, gateway 160 translates the user's mouse (or equivalent such as touch pad) click into a 

2 call set up request in the conventional format used by PSTN 120. 

3 Three possible configurations for placing a call from PC 100 are contemplated: dialer 

4 agent 1 05 resides in PC 1 0 1 as shown in Fig. 4A; dialer agent 1 52 resides in ISP 1 5 1 as shown in 

5 Fig. 4B; or dialer agent 1 56 resides in a third party provider or in a gateway accessible through 

6 Internet 1 55, as shown in Fig. 4C. 

7 Figs. 5A-5C are flow charts illustrating operation of the configuration of Fig. 3. Figs. 

8 5A-5C assume use of a hyper-text transfer protocol (HTTP) request/response architecture. In 

9 other embodiments, a Session Initiation Protocol (SIP) architecture is used, as discussed later 

10 below. 

1 1 Referring to Fig. 5 A, at step 405, a user uses PC 1 00 to log on to ISP 1 50 by establishing 

12 a modem connection from PC 100. 

13 At step 410, ISP 150 receives the log on request from PC 100. At step 415, ISP 150 

1 4 assigns a temporary internet protocol (IP) address to PC 1 00. At step 420, ISP 1 50 then replies 

15 to PC 1 00 by providing the home page requested by browser 1 03 , such as an HTTP response 

1 6 including HTML code for the home page selected by the user. 

1 7 At step 425, PC 1 00 receives the home page from ISP 1 50. Next, in activity not shown in 

1 8 Fig. 5 A, the user requests the home page of gateway 1 60, such as by entering the domain address 

1 9 into browser 1 03 or clicking on a "bookmark" (stored domain address with mnemonic identifier) 

20 stored locally in browser 1 03 or stored at remote location, or clicking on a predefined area of the 

2 1 home page of ISP 1 50. In response to the user's request, ISP 1 50 forwards the user's HTTP 

22 request packet to gateway 1 60, which replies with a HTTP response packet including HTML for 



498228 1 



PATENT 
IDS 113571 

1 the home page of gateway 160. At step 430, the user clicks on a predefined area of the home 

2 page of gateway 1 60, such as a "LAUNCH CALL" button. In response to the user's click, 

3 browser 1 03 prepares an appropriate HTTP request packet and sends the packet to ISP 1 50. 

4 It will be appreciated that if ISP 1 50 provides a "LAUNCH CALL" button on its 

5 homepage, or there is a "personal telephone book" application executing on PC 1 00, then the 

6 user need not receive the home page of gateway 1 60. 

7 At step 435, ISP 1 50 forwards the HTTP request packet for launching a telephone call to 

8 gateway 160. 

9 At step 440, gateway 1 60 receives the HTTP request packet for launching a telephone 

10 call. At step 445, gateway 160 provides an HTTP request packet including HTML representing 

1 1 a web page for telephone number entry to ISP 1 50. 

1 2 At step 450, ISP 1 50 forwards the HTTP response packet for telephone number entry to 

13 PC 100. 

14 At step 455, PC 1 00 receives the web page for telephone number entry. At step 460, the 

1 5 user enters (i) a toll-free telephone number to the telephone number entry web page to place a 

16 call to an agent at call center 70, and (ii) a telephone number, such as the telephone number of 

1 7 telephone 1 0, at which the user wishes to receive the call from the agent at call center 70. 

1 8 Browser 1 03 prepares a corresponding HTTP request packet including the toll-free called and 

1 9 reception telephone numbers. 

20 At step 465, ISP 1 50 forwards the HTTP request packet for the toll-free telephone 

2 1 number to gateway 1 60. 
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1 Fig. 6 is a diagram illustrating HTTP request message 700 forwarded to gateway 160 by 

2 ISP 150. HTTP request message 700 includes first line 710, second line 720 and third line 730. 

3 First line 710 is a request-line and includes method field 701, Request-URI field 703, 

4 protocol version field 705, and space delimiter (SP) fields 702, 704. Method field 701 indicates 

5 the method to be performed on the resource identified by the Request-URI field 703. In HTTP 

6 request message 700, the POST method is used to send data entered by the user to a form of a 

7 web page. Request-URI field 703 is a uniform resource identifier (URI) upon which to apply the 

8 request. HTTP version field 705 indicates the protocol and version for the HTTP request; in Fig. 

9 7, the protocol is seen to be HTTP and the version is " 1 . 1 ". 

10 Second line 720 comprises field identifier 721, delimiter 722 and parameter field 723. 

1 1 Field identifier 721 identifies the parameter, herein "called telephone number". Delimiter field 

12 722 includes the delimiter "=". Parameter field 723 contains the parameter value, 8001234567, 

1 3 assumed to be the toll-fi"ee telephone number of PBX 60. 

1 4 Third line 730 comprises field identifier 73 1 , delimiter 732 and parameter field 733. 

15 Field identifier 73 1 identifies the parameter, herein "receiving telephone number". Delimiter 

1 6 field 732 includes the delimiter "=". Parameter field 733 contains the parameter value, 

1 7 2129876543, assumed to be the telephone number of telephone 10 of subscriber premises 110 

1 8 which will receive the call being requested. 

19 At step 470, gateway 160 receives the HTTP request packet for the toll-free number from 

20 ISP 150 and, at step 475, gateway 160 assigns a temporary identifier to PC 100 based on its 

2 1 temporary IP address for this call, prepares a call set up request, and delivers the call set up 
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1 request to SCP/SN 140 of telecommunication network 120. Because PC 100 can laimch several 

2 calls simultaneously, gateway 160 uses a distinct temporary identifier for each call request. 

3 Fig. 7 is a diagram illustrating the general format of call set up request 800 prepared by 

4 gateway 160. Call set up request 800 includes lines 805, 810, 815, 820, 825, 830. Specific call 

5 set-up request formats are set forth in International Telecommunications Union (ITU) 

6 Recommendation Q.931 (May 1998) ISDN user-network interface layer 3 specification for basic 

7 call control, available from www.itu.org, the disclosure of which is hereby incorporated by 

8 reference. 

9 Line 805 identifies the source of the call set up request 800. In call set up request 800, 

1 0 the content of line 805 is "gateway 1 60" . 

1 1 Line 810 identifies the type of request. In call set up request 800, the content of line 810 

12 is "call set up". 

13 Line 815 includes the temporary identifier for this call request assigned at step 475. 

14 Line 820 identifies the called telephone number. In call set up request 800, the content of 

15 line 820 is the toll-free telephone number of PBX 60, 8001234567 in this example. 

16 Line 825 identifies the receiving telephone number. In call set up request 800, the 

17 content of line 825 is the telephone number for telephone 10, 2129876543 in this example. 

18 Line 830 contains other information. 

19 At step 480 of Fig. 5 A, SCP/SN 140 receives call set up request 800 for the toll-free 

20 number from gateway 160. 

21 Referring now to Fig. 53, upon receiving call set up request 800 from gateway 160, at 

22 step 485, SCP/SN 140 retrieves a stored record for the toll-free telephone number identified in 
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1 call set up request 800. The stored record for the toll-free number includes an actual telephone 

2 number and information including whether the called telephone number has "call center with 

3 queue length" service. 

4 Let it be assumed that the called phone number has "call center with queue length" 

5 service, and that the actual telephone number is associated with PBX 60. At step 490, SCP/SN 

6 140 queries queue manager 64 of PBX 60 as to whether a new call can be immediately 

7 connected to call center 70. As appropriate, SCP/SN 140 interacts with queue manager 64 that 

8 has the information regarding the availability of agent stations 72, 74, 76. 

9 Generally, SCP/SN 140 notifies queue manager 64 when there is a new call requesting 

10 service. Queue manager 64 responds to a new call notification from SCP/SN 140 by indicating 

1 1 either that the call can be serviced, or that the call must be queued. As an agent becomes 

12 available, queue manager 64 advises SCP/SN 140 that an enqueued call can be serviced. 

13 At step 495, queue manager 64 receives the query from SCP/SN 140. At step 500, queue 

14 manager 64 determines whether a new call can be accommodated by call center 70, such as by 

1 5 checking whether the number of calls in progress is less than the maximum which can be 

16 acconunodated by call center 70. If a call can be accommodated, processing proceeds to step 

17 540 of Fig. 5C. 

18 Let it be assumed that a call carmot be immediately connected. At step 505, queue 

19 manager 64 sends an unavailability reply to SCP/SN 140 and returns to step 500 to check 

20 whether a new call can be accommodated. 

21 At step 510, SCP/SN 140 receives the unavailability reply from queue manager 64. At 

22 step 515, SCP/SN 140 sends a status message to gateway 160 regarding the queue length of the 
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1 call placed by the user from PC 100 and estimating the time-in-queue for the call. For example, 

2 the status message contains information such as, "There are three calls ahead of you, and it will 

3 be about five mmutes until your call is served." Then, at step 516, SCP/SN 140 checks whether 

4 a predetermined amount of time has elapsed, and when it has, proceeds to step 5 1 9. 

5 At step 520, gateway 160 receives the call queue status message from SCP/SN 140. At 

6 step 525, gateway 160 prepares an HTTP reply packet including HTML representing a web page 

7 which includes the call queue status message, and provides the HTTP reply packet to ISP 150. 

8 At step 530, ISP 150 receives the HTTP reply packet for the call queue status information 

9 and forwards the HTTP reply packet to PC 1 00. 

10 At step 535, PC 100 receives the HTTP reply packet and browser 103 displays 

1 1 information regarding the call queue status of the telephone call placed by the user. 

12 The HTTP reply packet prepared by gateway 160 at step 525 need not represent a frill 

1 3 web page, and could instead represent a pop-up window for the browser display or a scrolling 

14 status line for the browser display. In another embodiment, the HTTP reply packet includes an 

1 5 audio announcement to be played by PC 1 00. 

16 Let it now be assumed that, at step 506 of Fig. 5B, call center 70 determines that a new 

1 7 call can be serviced, and notifies queue manager 64. At step 507, queue manager 64 forwards 

1 8 this notice to SCP/SN 1 40. 

1 9 At step 5 1 7, SCP/SN 1 40 receives notice that another call can be serviced. At step 5 1 8, 

20 SCP/SN 140 checks whether there are call requests that have been enqueued longer than the call 

2 1 request from PC 1 00. If not, then processing proceeds to step 570 of Fig. 5C. 
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1 If there are call requests ahead of the call request from PC 100, then at step 519, SCP/SN 

2 140 prepares an updated status message for PC 100, such as, "There are two calls ahead of you, 

3 and your wait will be about three minutes." and sends the updated status message to gateway 

4 1 60. SCP/SN 1 40 then returns to step 5 1 6 to wait for time to pass. 

5 At step 526, gateway 160 receives the status message prepared by SCP/SN 140. 

6 Processing proceeds to step 525, resulting in an updated status message being sent to PC 100. 

7 Referring now to Fig. 5C, at step 540, queue manager 64 sends an availability reply to 

8 SCP/SN 140. At step 545, which may be performed substantially simultaneously with step 540, 

9 queue manager 64 instructs router 62 to cotmect the call to call center 70 for delivery to an 

10 available agent. 

11 At step 550, router 62 receives the call connection instruction from queue manager 64. 

12 At step 550, a voiceband cormection is established between PBX 60 and call center 70 for the 

13 call. At step 555, router 62 cormects an available agent to the incoming call, and, at step 560, a 

14 call path is established between telephone 10 and an agent at one of stations 72, 74, 76. 

15 Meanwhile, at step 565, SCP/SN 140 receives the availability reply from queue manager 

16 64. At step 570, SCP/SN 140 instructs switch 130 to connect telephone 10 to the telephone 

17 number associated with PBX 60, as obtained from the stored record retrieved by SCP/SN 140 at 

18 step 485 in Fig. 5B. 

19 At step 575, SCP/SN 140 sends a call status message to gateway 160 for delivery to PC 

20 100. 

21 At step 605, gateway 160 receives the call status message from SCP/SN 140 and, at step 

22 610, creates a corresponding HTTP response packet including appropriate HTML for displaying 
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1 the call status as a web page, window or status update on a scrolling line of browser 103, and 

2 provides the HTTP response packet to ISP 1 50. 

3 At step 615, ISP 150 forwards the HTTP response packet for the call status to PC 100. 

4 At step 620, PC 100 receives the HTTP response packet and browser 103 displays the 

5 call status information to the user of PC 100 indicating that the requested telephone call is being 

6 placed. 

7 At step 580, switch 130 receives the call connection instruction from SCP/SN 1 40. At 

8 the start of step 580, switch 130 lacks comiections to subscriber premises 1 10 and corporate 

9 premises 80. To establish a circuit switched voice path between telephone 10 of subscriber 

10 premises 1 10 and PBX 60 of corporate premises 80, the control or signaling network of PSTN 

1 1 120 is utilized by switch 130 to locate and reserve suitable circuit segments. At step 585, switch 

12 130 uses the PSTN signaling network to set up a voiceband connection to PBX 60, and at step 

13 590, switch 130 uses the PSTN signaling network to set up a voiceband comiection to telephone 

14 10. At step 600, a call path is established between telephone 10 and PBX 60 which, in turn, is 

1 5 connected to an agent at one of stations 72, 74, 76. 

16 At step 625, telephone 10 receives a ring signal from switch 130 for the call launched 

17 from PC 100 at step 460. At step 630, the user picks up the handset of telephone 10 causing 

18 telephone 10 to be off-hook, and telephone 10 has a call path to the available agent at corporate 

19 premises 80. 

20 The technique of delivering call queue status messages described with reference to Figs. 

21 5A-5C does not rely on intelligent peripherals in PSTO 120, and thus avoids the prior art 

22 problems associated with relying on intelligent peripherals. Another advantage of the present 
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1 technique is that it does not consume ports on switch 130 or use telephone 10 until an agent at 

2 call center 70 is available to service the subscriber. 

3 SIP is an application layer control protocol for creating, modifying and terminating 

4 sessions with multiple participants. SIP is independent of the lower layer transport protocol, 

5 which is usually TCP/UDP, but may be ATM AAL5, IPX, frame relay, X.25 or the like. In the 

6 SIP architecture, clients send requests, while servers service requests and reply to clients by 

7 sending responses. SIP has been published as Internet Engineering Task Force (IETF) standard 

8 RFC 2543, available at ftp://ftp.isi.edu/in-notes/rfc2543.txt, the disclosure of which is hereby 

9 incorporated by reference. 

1 0 When SIP is used, PC 1 00 is a SIP client and gateway 1 60 is a SIP proxy server. 

1 1 SCP/SN 140 also acts as a SIP proxy server. 

12 Generally, the user of PC 100 clicks an area to establish a telephone connection, as 

13 described above with respect to step 430 of Fig. 5A. A SIP URL with the INVITE method can 

14 be used as a hyperlink, so the user is typically unaware of whether a connection is being made 

1 5 using HTTP or SIP messages. 

1 6 Gateway 1 60 receives the SIP INVITE request message from PC 1 00 and responds to PC 

17 1 00 with SIP informational status response such as " 1 00 Trying", "180 ringing", " 1 82 Queued, 2 

1 8 callers ahead" and so on. Functioning as a proxy, gateway 1 60 forwards the SIP INVITE request 

19 to SCP/SN 140. 

20 SCP/SN 140 receives the SIP INVITE message from gateway 160 and responds to 

2 1 gateway 1 60 with SIP informational status responses as described above. Meanwhile, SCP/SN 

22 140 tries to establish a connection to PBX 60, as described above. When PBX 60 accepts the 
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1 new call, SCP/SN 140 sends a SIP informational status response to gateway 160 (see step 575 of 

2 Fig. 5C), and the voiceband call is established as described in steps 552, 555, 585, 590, 625, 630, 

3 600, 560 and 635 of Fig. 5C. When PBX 60 accepts a new call request, but there are other call 

4 requests ahead of the request from PC 1 10, processing proceeds in similar mamier as described 

5 above. 



Although illustrative embodiments of the present invention, and various 
modifications thereof, have been described in detail herein with reference to the accompanying 

8 drawings, it is to be understood that the invention is not limited to these precise embodiments 

9 and the described modifications, and that various changes and further modifications may be 

10 effected therein by one skilled in the art without departing from the scope or spirit of the 

1 1 invention as defined in the appended claims. 
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